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Abstract 


This document defines requirements for IPv6 nodes. It is expected 
that IPv6 will be deployed in a wide range of devices and situations. 
Specifying the requirements for IPv6 nodes allows IPv6 to function 
well and interoperate in a large number of situations and 
deployments. 


This document obsoletes RFC 4294. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6434. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
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Les 


Introduction 


This document defines common functionality required from both IPv6 
hosts and routers. Many IPv6 nodes will implement optional or 
additional features, but this document collects and summarizes 
requirements from other published Standards Track documents in one 
place. 


This document tries to avoid discussion of protocol details and 
references RFCs for this purpose. This document is intended to be an 
applicability statement and to provide guidance as to which IPv6 
specifications should be implemented in the general case and which 
specifications may be of interest to specific deployment scenarios. 
This document does not update any individual protocol document RFCs. 


Although this document points to different specifications, it should 
be noted that in many cases, the granularity of a particular 
requirement will be smaller than a single specification, as many 
specifications define multiple, independent pieces, some of which may 
not be mandatory. In addition, most specifications define both 
client and server behavior in the same specification, while many 
implementations will be focused on only one of those roles. 


This document defines a minimal level of requirement needed for a 
device to provide useful internet service and considers a broad range 
of device types and deployment scenarios. Because of the wide range 
of deployment scenarios, the minimal requirements specified in this 
document may not be sufficient for all deployment scenarios. It is 
perfectly reasonable (and indeed expected) for other profiles to 
define additional or stricter requirements appropriate for specific 
usage and deployment environments. For example, this document does 
not mandate that all clients support DHCP, but some deployment 
scenarios may deem it appropriate to make such a requirement. For 
example, government agencies in the USA have defined profiles for 
specialized requirements for IPv6 in target environments (see [DODv6] 
and [USGv6]). 


As it is not always possible for an implementer to know the exact 
usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 
that they should adhere to Jon Postel’s Robustness Principle: "Be 
conservative in what you do, be liberal in what you accept from 
others" [RFC0O793]. 
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1.1. Scope of This Document 
IPv6 covers many specifications. It is intended that IPv6 will be 
deployed in many different situations and environments. Therefore, 
it is important to develop requirements for IPv6 nodes to ensure 
interoperability. 


This document assumes that all IPv6 nodes meet the minimum 
requirements specified here. 


1.2. Description of IPv6 Nodes 


From the Internet Protocol, Version 6 (IPv6) Specification [RFC2460], 
we have the following definitions: 


IPv6 node - a device that implements IPv6. 


IPv6 router - a node that forwards IPv6 packets not explicitly 
addressed to itself. 


IPv6 host - any node that is not a router. 
2. Requirements Language 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

document are to be interpreted as described in RFC 2119 [RFC2119]. 
3. Abbreviations Used in This Document 

ATM Asynchronous Transfer Mode 

AH Authentication Header 

DAD Duplicate Address Detection 

ESP Encapsulating Security Payload 

ICMP Internet Control Message Protocol 

IKE Internet Key Exchange 

MIB Management Information Base 


MLD Multicast Listener Discovery 


MTU Maximum Transmission Unit 
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NA Neighbor Advertisement 
NBMA Non-Broadcast Multiple Access 
ND Neighbor Discovery 


NS Neighbor Solicitation 


NUD Neighbor Unreachability Detection 
PPP Point-to-Point Protocol 

4. Sub-IP Layer 
An IPv6 node must include support for one or more IPv6 link-layer 
specifications. Which link-layer specifications an implementation 
should include will depend upon what link-layers are supported by the 
hardware available on the system. It is possible for a conformant 
IPv6 node to support IPv6 on some of its interfaces and not on 
others. 
As IPv6 is run over new layer 2 technologies, it is expected that new 
specifications will be issued. In the following, we list some of the 
layer 2 technologies for which an IPv6 specification has been 
developed. It is provided for informational purposes only and may 
not be complete. 
- Transmission of IPv6 Packets over Ethernet Networks [RFC2464] 


- IPv6 over ATM Networks [RFC2492] 


- Transmission of IPv6 Packets over Frame Relay Networks 
Specification [RFC2590] 


- Transmission of IPv6 Packets over IEEE 1394 Networks [RFC3146] 


- Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) 
Packets over Fibre Channel [RFC4338] 


- Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944] 


- Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 
802.16 Networks [RFC5121] 


- IP version 6 over PPP [RFC5072] 
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In addition to traditional physical link-layers, it is also possible 
to tunnel IPv6 over other protocols. Examples include: 


- Teredo: Tunneling IPv6 over UDP through Network Address 
Translations (NATs) [RFC4380] 


- Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and 
Routers" [RFC4213] 


5. IP Layer 
5.1. Internet Protocol Version 6 - RFC 2460 


The Internet Protocol Version 6 is specified in [RFC2460]. This 
specification MUST be supported. 


Any unrecognized extension headers or options MUST be processed as 
described in RFC 2460. 


The node MUST follow the packet transmission rules in RFC 2460. 


Nodes MUST always be able to send, receive, and process fragment 
headers. All conformant IPv6 implementations MUST be capable of 
sending and receiving IPv6 packets; the forwarding functionality MAY 
be supported. Overlapping fragments MUST be handled as described in 
[RFC5722]. 


RFC 2460 specifies extension headers and the processing for these 
headers. 


An IPv6 node MUST be able to process these headers. An exception is 
Routing Header type 0 (RHO), which was deprecated by [RFC5095] due to 
security concerns and which MUST be treated as an unrecognized 
routing type. 


All nodes SHOULD support the setting and use of the IPv6 Flow Label 
field as defined in the IPv6 Flow Label specification [RFC6437]. 
Forwarding nodes such as routers and load distributors MUST NOT 
depend only on Flow Label values being uniformly distributed. It is 
RECOMMENDED that source hosts support the flow label by setting the 
Flow Label field for all packets of a given flow to the same value 
chosen from an approximation to a discrete uniform distribution. 
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5.2. Neighbor Discovery for IPv6 - RFC 4861 


Neighbor Discovery is defined in [RFC4861]; the definition was 
updated by [RFC5942]. Neighbor Discovery SHOULD be supported. RFC 
4861 states: 


Unless specified otherwise (in a document that covers operating IP 
over a particular link type) this document applies to all link 
types. However, because ND uses link-layer multicast for some of 
its services, it is possible that on some link types (e.g., Non- 
Broadcast Multi-Access (NBMA) links), alternative protocols or 
mechanisms to implement those services will be specified (in the 
appropriate document covering the operation of IP over a 
particular link type). The services described in this document 
that are not directly dependent on multicast, such as Redirects, 
next-hop determination, Neighbor Unreachability Detection, etc., 


are expected to be provided as specified in this document. The 
details of how one uses ND on NBMA links are addressed in 
[RFC2491]. 


Some detailed analysis of Neighbor Discovery follows: 


Router Discovery is how hosts locate routers that reside on an 
attached link. Hosts MUST support Router Discovery functionality. 


Prefix Discovery is how hosts discover the set of address prefixes 
that define which destinations are on-link for an attached link. 
Hosts MUST support Prefix Discovery. 


Hosts MUST also implement Neighbor Unreachability Detection (NUD) for 
all paths between hosts and neighboring nodes. NUD is not required 
for paths between routers. However, all nodes MUST respond to 
unicast Neighbor Solicitation (NS) messages. 


Hosts MUST support the sending of Router Solicitations and the 
receiving of Router Advertisements. The ability to understand 
individual Router Advertisement options is dependent on supporting 
the functionality making use of the particular option. 


All nodes MUST support the sending and receiving of Neighbor 
Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and 
NA messages are required for Duplicate Address Detection (DAD). 


Hosts SHOULD support the processing of Redirect functionality. 
Routers MUST support the sending of Redirects, though not necessarily 
for every individual packet (e.g., due to rate limiting). Redirects 
are only useful on networks supporting hosts. In core networks 
dominated by routers, Redirects are typically disabled. The sending 
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of Redirects SHOULD be disabled by default on backbone routers. They 
MAY be enabled by default on routers intended to support hosts on 
edge networks. 


"IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional 
recommendations on how to select from a set of available routers. 
[RFC4311] SHOULD be supported. 


5.3. Default Router Preferences and More-Specific Routes - RFC 4191 


"Default Router Preferences and More-Specific Routes" [RFC4191] 
provides support for nodes attached to multiple (different) networks, 
each providing routers that advertise themselves as default routers 
via Router Advertisements. In some scenarios, one router may provide 
connectivity to destinations the other router does not, and choosing 
the "wrong" default router can result in reachability failures. In 
such cases, RFC 4191 can help. 


Small Office/Home Office (SOHO) deployments supported by routers 
adhering to [RFC6204] use RFC 4191 to advertise routes to certain 
local destinations. Consequently, nodes that will be deployed in 
SOHO environments SHOULD implement RFC 4191. 


5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 


SEND [RFC3971] and Cryptographically Generated Address (CGA) 
[RFC3972] provide a way to secure the message exchanges of Neighbor 
Discovery. SEND is a new technology in that it has no IPv4 
counterpart, but it has significant potential to address certain 
classes of spoofing attacks. While there have been some 
implementations of SEND, there has been only limited deployment 
experience to date in using the technology. In addition, the IETF 
working group Cga & Send maIntenance (csi) is currently working on 
additional extensions intended to make SEND more attractive for 
deployment. 


At this time, SEND is considered optional, and IPv6 nodes MAY provide 
SEND functionality. 


5.5. IPv6 Router Advertisement Flags Option - RFC 5175 


Router Advertisements include an 8-bit field of single-bit Router 
Advertisement flags. The Router Advertisement Flags Option extends 
the number of available flag bits by 48 bits. At the time of this 
writing, 6 of the original 8 single-bit flags have been assigned, 
while 2 remain available for future assignment. No flags have been 
defined that make use of the new option, and thus, strictly speaking, 
there is no requirement to implement the option today. However, 
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implementations that are able to pass unrecognized options to a 
higher-level entity that may be able to understand them (e.g., a 
user-level process using a "raw socket" facility) MAY take steps to 
handle the option in anticipation of a future usage. 


5.6. Path MTU Discovery and Packet Size 
5.6.1. Path MTU Discovery - RFC 1981 


"Path MTU Discovery for IP version 6" [RFC1981] SHOULD be supported. 
From [RFC2460]: 


It is strongly recommended that IPv6 nodes implement Path MTU 
Discovery [RFC1981], in order to discover and take advantage of 
path MTUs greater than 1280 octets. However, a minimal IPv6 
implementation (e.g., in a boot ROM) may simply restrict itself to 
sending packets no larger than 1280 octets, and omit 
implementation of Path MTU Discovery. 


The rules in [RFC2460] and [RFC5722] MUST be followed for packet 
fragmentation and reassembly. 


One operational issue with Path MTU Discovery occurs when firewalls 
block ICMP Packet Too Big messages. Path MTU Discovery relies on 
such messages to determine what size messages can be successfully 
sent. "Packetization Layer Path MTU Discovery" [RFC4821] avoids 
having a dependency on Packet Too Big messages. 


5.7. IPv6 Jumbograms - RFC 2675 
IPv6 Jumbograms [RFC2675] are an optional extension that allow the 
sending of IP datagrams larger than 65.535 bytes. IPv6é Jumbograms 
make use of IPv6 hop-by-hop options and are only suitable on paths in 
which every hop and link are capable of supporting Jumbograms (e.g., 
within a campus or datacenter). To date, few implementations exist, 
and there is essentially no reported experience from usage. 
Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time. 

5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 


ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi- 
Part Messages" [RFC4884] MAY be supported. 
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5.9. Addressing 
5.9.1. IP Version 6 Addressing Architecture - RFC 4291 

The IPv6 Addressing Architecture [RFC4291] MUST be supported. 
5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 


Hosts MUST support IPv6 Stateless Address Autoconfiguration as 
defined in [RFC4862]. Configuration of static address(es) may be 
supported as well. 


Nodes that are routers MUST be able to generate link-local addresses 
as described in [RFC4862]. 


From RFC 4862: 


The autoconfiguration process specified in this document applies 
only to hosts and not routers. Since host autoconfiguration uses 
information advertised by routers, routers will need to be 
configured by some other means. However, it is expected that 
routers will generate link-local addresses using the mechanism 
described in this document. In addition, routers are expected to 
successfully pass the Duplicate Address Detection procedure 
described in this document on all addresses prior to assigning 
them to an interface. 


All nodes MUST implement Duplicate Address Detection. Quoting from 
Section 5.4 of RFC 4862: 


Duplicate Address Detection MUST be performed on all unicast 
addresses prior to assigning them to an interface, regardless of 
whether they are obtained through stateless autoconfiguration, 
DHCPv6, or manual configuration, with the following [exceptions 
noted therein]. 


"Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] 
specifies a mechanism to reduce delays associated with generating 
addresses via Stateless Address Autoconfiguration [RFC4862]. RFC 
4429 was developed in conjunction with Mobile IPv6 in order to reduce 
the time needed to acquire and configure addresses as devices quickly 
move from one network to another, and it is desirable to minimize 
transition delays. For general purpose devices, RFC 4429 remains 
optional at this time. 
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5.9.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 


Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] 
addresses a specific problem involving a client device whose user is 
concerned about its activity or location being tracked. The problem 
arises both for a static client and for one that regularly changes 
its point of attachment to the Internet. When using Stateless 
Address Autoconfiguration [RFC4862], the Interface Identifier portion 
of formed addresses stays constant and is globally unique. Thus, 
although a node's global IPv6 address will change if it changes its 
point of attachment, the Interface Identifier portion of those 
addresses remains the same, making it possible for servers to track 
the location of an individual device as it moves around or its 
pattern of activity if it remains in one place. This may raise 
privacy concerns as described in [RFC4862]. 


In such situations, RFC 4941 SHOULD be implemented. In other cases, 
such as with dedicated servers in a data center, RFC 4941 provides 
limited or no benefit. 


Implementers of RFC 4941 should be aware that certain addresses are 
reserved and should not be chosen for use as temporary addresses. 
Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more 
details. 


5.9.4. Default Address Selection for IPv6 - RFC 3484 


The rules specified in the Default Address Selection for IPv6 
[RFC3484] document MUST be implemented. IPv6 nodes will need to deal 
with multiple addresses configured simultaneously. 


5.9.5. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 


DHCPv6 [RFC3315] can be used to obtain and configure addresses. In 
general, a network may provide for the configuration of addresses 
through Router Advertisements, DHCPv6, or both. There will be a wide 
range of IPv6 deployment models and differences in address assignment 
requirements, some of which may require DHCPv6 for address 
assignment. Consequently, all hosts SHOULD implement address 
configuration via DHCPv6. 


In the absence of a router, IPv6 nodes using DHCP for address 
assignment MAY initiate DHCP to obtain IPv6 addresses and other 
configuration information, as described in Section 5.5.2 of 
[RFC4862]. 
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5.10. Multicast Listener Discovery (MLD) for IPv6 


Nodes that need to join multicast groups MUST support MLDv1 


[RFC2710]. MLDvl is needed by any node that is expected to receive 
and process multicast traffic. Note that Neighbor Discovery (as used 
on most link types -- see Section 5.2) depends on multicast and 


requires that nodes join Solicited Node multicast addresses. 


MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting 
Source-Specific Multicast. The original MLDv2 protocol [RFC3810] 
supporting Source-Specific Multicast [RFC4607] supports two types of 
"filter modes". Using an INCLUDE filter, a node indicates a 
multicast group along with a list of senders for the group from which 
it wishes to receive traffic. Using an EXCLUDE filter, a node 
indicates a multicast group along with a list of senders from which 
it wishes to exclude receiving traffic. In practice, operations to 
block source(s) using EXCLUDE mode are rarely used but add 
considerable implementation complexity to MLDv2. Lightweight MLDv2 
[RFC5790] is a simplified subset of the original MLDv2 specification 
that omits EXCLUDE filter mode to specify undesired source(s). 


Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2 
[RFC5790]. Specifically, nodes supporting applications using Source- 
Specific Multicast that expect to take advantage of MLDv2’s EXCLUDE 
functionality [RFC3810] MUST support MLDv2 as defined in [RFC3810], 
[RFC4604], and [RFC4607]. Nodes supporting applications that expect 
to only take advantage of MLDv2’s INCLUDE functionality as well as 
Any-Source Multicast will find it sufficient to support MLDv2 as 
defined in [RFC5790]. 


If a node only supports applications that use Any-Source Multicast 
(i.e, they do not use Source-Specific Multicast), implementing MLDv1 
[RFC2710] is sufficient. In all cases, however, nodes are strongly 
encouraged to implement MLDv2 or Lightweight MLDv2 rather than MLDvl, 
as the presence of a single MLDvl participant on a link requires that 
all other nodes on the link operate in version 1 compatibility mode. 


When MLDv1 is used, the rules in the Source Address Selection for the 
Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be 
followed. 


6. DHCP versus Router Advertisement Options for Host Configuration 


In IPv6, there are two main protocol mechanisms for propagating 
configuration information to hosts: Router Advertisements (RAs) and 
DHCP. Historically, RA options have been restricted to those deemed 
essential for basic network functioning and for which all nodes are 
configured with exactly the same information. Examples include the 
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Prefix Information Options, the MTU option, etc. On the other hand, 
DHCP has generally been preferred for configuration of more general 
parameters and for parameters that may be client-specific. That 
said, identifying the exact line on whether a particular option 
should be configured via DHCP versus an RA option has not always been 
easy. Generally speaking, however, there has been a desire to define 
only one mechanism for configuring a given option, rather than 
defining multiple (different) ways of configuring the same 
information. 


One issue with having multiple ways of configuring the same 
information is that interoperability suffers if a host chooses one 
mechanism but the network operator chooses a different mechanism. 
For "closed" environments, where the network operator has significant 
influence over what devices connect to the network and thus what 
configuration mechanisms they support, the operator may be able to 
ensure that a particular mechanism is supported by all connected 
hosts. In more open environments, however, where arbitrary devices 
may connect (e.g., a WIFI hotspot), problems can arise. To maximize 
interoperability in such environments, hosts would need to implement 
multiple configuration mechanisms to ensure interoperability. 


Originally, in IPv6, configuring information about DNS servers was 


performed exclusively via DHCP. In 2007, an RA option was defined 
but was published as Experimental [RFC5006]. In 2010, "IPv6 Router 
Advertisement Options for DNS Configuration" [RFC6106] was published 
as a Standards Track document. Consequently, DNS configuration 


information can now be learned either through DHCP or through RAs. 
Hosts will need to decide which mechanism (or whether both) should be 
implemented. Specific guidance regarding DNS server discovery is 
discussed in Section 7. 


7. DNS and DHCP 
7.1. DNS 


DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596]. 
Not all nodes will need to resolve names; those that will never need 
to resolve DNS names do not need to implement resolver functionality. 
However, the ability to resolve names is a basic infrastructure 
capability on which applications rely, and most nodes will need to 
provide support. All nodes SHOULD implement stub-resolver [RFC1034] 
functionality, as in [RFC1034], Section 5.3.1, with support for: 


- AAAA type Resource Records [RFC3596]; 


- reverse addressing in ip6.arpa using PTR records [RFC3596]; 
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- Extension Mechanisms for DNS (EDNSO) [RFC2671] to allow for DNS 
packet sizes larger than 512 octets. 


Those nodes are RECOMMENDED to support DNS security extensions 
[RFC4033] [RFC4034] [RFC4035]. 


Those nodes are NOT RECOMMENDED to support the experimental A6 
Resource Records [RFC3363]. 


7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 
7.2.1. Other Configuration Information 


IPv6 nodes use DHCP [RFC3315] to obtain address configuration 
information (see Section 5.9.5) and to obtain additional (non- 
address) configuration. If a host implementation supports 
applications or other protocols that require configuration that is 
only available via DHCP, hosts SHOULD implement DHCP. For 
specialized devices on which no such configuration need is present, 
DHCP may not be necessary. 


An IPv6 node can use the subset of DHCP (described in [RFC3736]) to 
obtain other configuration information. 


7.2.2. Use of Router Advertisements in Managed Environments 
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 


are expected to determine their default router information and on- 
link prefix information from received Router Advertisements. 


7.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 6106 


Router Advertisements have historically limited options to those that 
are critical to basic IPv6 functioning. Originally, DNS 
configuration was not included as an RA option, and DHCP was the 
recommended way to obtain DNS configuration information. Over time, 
the thinking surrounding such an option has evolved. It is now 
generally recognized that few nodes can function adequately without 
having access to a working DNS resolver. [RFC5006] was published as 
an Experimental document in 2007, and recently, a revised version was 
placed on the Standards Track [RFC6106]. 


Implementations SHOULD implement the DNS RA option [RFC6106]. 
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8. IPv4 Support and Transition 


IPv6 nodes MAY support IPv4. 


8.1. Transition Mechanisms 
8.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 
4213 


If an IPv6 node implements dual stack and tunneling, then [RFC4213] 
MUST be supported. 


9. Application Support 
9.1. Textual Representation of IPv6 Addresses - RFC 5952 


Software that allows users and operators to input IPv6 addresses in 
text form SHOULD support "A Recommendation for IPv6 Address Text 
Representation" [RFC5952]. 


9.2. Application Programming Interfaces (APIs) 


There are a number of IPv6-related APIs. This document does not 
mandate the use of any, because the choice of API does not directly 
relate to on-the-wire behavior of protocols. Implementers, however, 
would be advised to consider providing a common API or reviewing 
existing APIs for the type of functionality they provide to 
applications. 


"Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6 
functionality used by typical applications. Implementers should note 
that RFC3493 has been picked up and further standardized by the 
Portable Operating System Interface (POSIX) [POSIX]. 


"Advanced Sockets Application Program Interface (API) for IPv6" 
[RFC3542] provides access to advanced IPv6 features needed by 
diagnostic and other more specialized applications. 


"IPv6 Socket API for Source Address Selection" [RFC5014] provides 
facilities that allow an application to override the default Source 
Address Selection rules of [RFC3484]. 


"Socket Interface Extensions for Multicast Source Filters" [RFC3678] 
provides support for expressing source filters on multicast group 
memberships. 
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10. 


Vie. 


"Extension to Sockets API for Mobile IPv6" [RFC4584] provides 
application support for accessing and enabling Mobile IPv6 [RFC6275] 
features. 


Mobility 
Mobile IPv6 [RFC6275] and associated specifications [RFC3776] 
[RFC4877] allow a node to change its point of attachment within the 
Internet, while maintaining (and using) a permanent address. All 
communication using the permanent address continues to proceed as 
expected even as the node moves around. The definition of Mobile IP 
includes requirements for the following types of nodes: 

- mobile nodes 


- correspondent nodes with support for route optimization 


- home agents 


all IPv6 routers 


At the present time, Mobile IP has seen only limited implementation 
and no significant deployment, partly because it originally assumed 
an IPv6-only environment rather than a mixed IPv4/IPv6 Internet. 
Recently, additional work has been done to support mobility in mixed- 
mode IPv4 and IPv6 networks [RFC5555]. 


More usage and deployment experience is needed with mobility before 
any specific approach can be recommended for broad implementation in 
all hosts and routers. Consequently, [RFC6275], [RFC5555], and 
associated standards such as [RFC4877] are considered a MAY at this 
time. 


Security 


This section describes the specification for security for IPv6 nodes. 


Achieving security in practice is a complex undertaking. Operational 
procedures, protocols, key distribution mechanisms, certificate 
management approaches, etc., are all components that impact the level 
of security actually achieved in practice. More importantly, 
deficiencies or a poor fit in any one individual component can 
significantly reduce the overall effectiveness of a particular 
security approach. 
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IPsec provides channel security at the Internet layer, making it 
possible to provide secure communication for all (or a subset of) 
communication flows at the IP layer between pairs of internet nodes. 
IPsec provides sufficient flexibility and granularity that individual 
TCP connections can (selectively) be protected, etc. 


Although IPsec can be used with manual keying in some cases, such 
usage has limited applicability and is not recommended. 


A range of security technologies and approaches proliferate today 
(e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), 
etc.) No one approach has emerged as an ideal technology for all 
needs and environments. Moreover, IPsec is not viewed as the ideal 
security technology in all cases and is unlikely to displace the 
others. 


Previously, IPv6 mandated implementation of IPsec and recommended the 
key management approach of IKE. This document updates that 
recommendation by making support of the IPsec Architecture [RFC4301] 
a SHOULD for all IPv6 nodes. Note that the IPsec Architecture 
requires (e.g., Section 4.5 of RFC 4301) the implementation of both 
manual and automatic key management. Currently, the default 
automated key management protocol to implement is IKEv2 [RFC5996]. 


This document recognizes that there exists a range of device types 
and environments where approaches to security other than IPsec can be 
justified. For example, special-purpose devices may support only a 
very limited number or type of applications, and an application- 
specific security approach may be sufficient for limited management 
or configuration capabilities. Alternatively, some devices may run 
on extremely constrained hardware (e.g., sensors) where the full 
IPsec Architecture is not justified. 


11.1. Requirements 


"Security Architecture for the Internet Protocol" [RFC4301] SHOULD be 
supported by all IPv6 nodes. Note that the IPsec Architecture 
requires (e.g., Section 4.5 of [RFC4301]) the implementation of both 
manual and automatic key management. Currently, the default 
automated key management protocol to implement is IKEv2. As required 
in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST 
implement ESP [RFC4303] and MAY implement AH [RFC4302]. 
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T2; 


12 


12 


12), 


-2. Transforms and Algorithms 


The current set of mandatory-to-implement algorithms for the IPsec 
Architecture are defined in "Cryptographic Algorithm Implementation 
Requirements For ESP and AH" [RFC4835]. IPv6 nodes implementing the 
IPsec Architecture MUST conform to the requirements in [RFC4835]. 
Preferred cryptographic algorithms often change more frequently than 
security protocols. Therefore, implementations MUST allow for 
migration to new algorithms, as RFC 4835 is replaced or updated in 
the future. 


The current set of mandatory-to-implement algorithms for IKEv2 are 
defined in "Cryptographic Algorithms for Use in the Internet Key 
Exchange Version 2 (IKEv2)" [RFC4307]. IPv6 nodes implementing IKEv2 
MUST conform to the requirements in [RFC4307] and/or any future 
updates or replacements to [RFC4307]. 


Router-Specific Functionality 


This section defines general host considerations for IPv6 nodes that 
act as routers. Currently, this section does not discuss routing- 
specific requirements. 


1. IPv6 Router Alert Option - RFC 2711 


The IPv6 Router Alert Option [RFC2711] is an optional IPv6 Hop-by-Hop 
Header that is used in conjunction with some protocols (e.g., RSVP 
[RFC2205] or Multicast Listener Discovery (MLD) [RFC2710]). The 
Router Alert option will need to be implemented whenever protocols 
that mandate its usage (e.g., MLD) are implemented. See 

Section 5.10. 


-2. Neighbor Discovery for IPv6 - RFC 4861 


Sending Router Advertisements and processing Router Solicitations 
MUST be supported. 


Section 7 of [RFC6275] includes some mobility-specific extensions to 
Neighbor Discovery. Routers SHOULD implement Sections 7.3 and 7.5, 
even if they do not implement Home Agent functionality. 


3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 


A single DHCP server ([RFC3315] or [RFC4862]) can provide 
configuration information to devices directly attached to a shared 
link, as well as to devices located elsewhere within a site. 
Communication between a client and a DHCP server located on different 
links requires the use of DHCP relay agents on routers. 
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In simple deployments, consisting of a single router and either a 
single LAN or multiple LANs attached to the single router, together 
with a WAN connection, a DHCP server embedded within the router is 
one common deployment scenario (e.g., [RFC6204]). However, there is 
no need for relay agents in such scenarios. 


In more complex deployment scenarios, such as within enterprise or 
service provider networks, the use of DHCP requires some level of 
configuration, in order to configure relay agents, DHCP servers, etc. 
In such environments, the DHCP server might even be run ona 
traditional server, rather than as part of a router. 


Because of the wide range of deployment scenarios, support for DHCP 
server functionality on routers is optional. However, routers 
targeted for deployment within more complex scenarios (as described 
above) SHOULD support relay agent functionality. Note that "Basic 


Requirements for IPv6 Customer Edge Routers" [RFC6204] requires 
implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) 
routers. 


13. Network Management 


Network management MAY be supported by IPv6 nodes. However, for IPv6 
nodes that are embedded devices, network management may be the only 
possible way of controlling these nodes. 


13.1. Management Information Base (MIB) Modules 


The following two MIB modules SHOULD be supported by nodes that 
support a Simple Network Management Protocol (SNMP) agent. 


13.1.1. IP Forwarding Table MIB 


The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes 
that support an SNMP agent. 


13.1.2. Management Information Base for the Internet Protocol (IP) 


The IP MIB [RFC4293] SHOULD be supported by nodes that support an 
SNMP agent. 


14. Security Considerations 
This document does not directly affect the security of the Internet, 
beyond the security considerations associated with the individual 


protocols. 


Security is also discussed in Section 11 above. 
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Appendix: Changes from RFC 4294 
There have been many editorial clarifications as well as significant 
additions and updates. While this section highlights some of the 
changes, readers should not rely on this section for a comprehensive 


list of all changes. 


1. Updated the Introduction to indicate that this document is an 
applicability statement and is aimed at general nodes. 


2% Significantly updated the section on Mobility protocols, adding 
references and downgrading previous SHOULDs to MAYs. 


3s Changed Sub-IP Layer section to just list relevant RFCs, and 
added some more RFCs. 


4. Added section on SEND (it is a MAY). 


oe Revised section on Privacy Extensions [RFC4941] to add more 
nuance to recommendation. 


6. Completely revised IPsec/IKEv2 section, downgrading overall 
recommendation to a SHOULD. 


7. Upgraded recommendation of DHCPv6 to SHOULD. 
8. Added background section on DHCP versus RA options, added SHOULD 
recommendation for DNS configuration via RAs [RFC6106], and 


cleaned up DHCP recommendations. 


9i Added recommendation that routers implement Sections 7.3 and 7.5 
of [RFC6275]. 


10. Added pointer to subnet clarification document [RFC5942]. 
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11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] 
SHOULD be implemented. 


12. Added reference to [RFC5722] (Overlapping Fragments), and made 
it a MUST to implement. 


13. Made "A Recommendation for IPv6 Address Text Representation" 
[RFC5952] a SHOULD. 


14. Removed mention of "DNAME" from the discussion about [RFC3363]. 


15. Numerous updates to reflect newer versions of IPv6 documents, 
including [RFC4443], [RFC4291], [RFC3596], and [RFC4213]. 


16. Removed discussion of "Managed" and "Other" flags in RAs. There 
is no consensus at present on how to process these flags, and 
discussion of their semantics was removed in the most recent 
update of Stateless Address Autoconfiguration [RFC4862]. 


17. Added many more references to optional IPv6 documents. 


18. Made "A Recommendation for IPv6 Address Text Representation" 
[RFC5952] a SHOULD. 


19. Added reference to [RFC5722] (Overlapping Fragments), and made 
it a MUST to implement. 


20. Updated MLD section to include reference to Lightweight MLD 
[RFC5790]. 


21. Added SHOULD recommendation for "Default Router Preferences and 
More-Specific Routes" [RFC4191]. 


22. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD. 
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